Enhanced authentication security applicable in an at least partially insecure network environment

ABSTRACT

Systems and methods are provided for enhancing the security of a multi-system transaction environment in which the computer hardware and/or software of at least one device participating in transaction authorization does not support encrypted communications, and/or where at least one communication associated with the transaction is sent over a network in a manner that will likely be capable of being intercepted, listened to or monitored by an untrusted party. An authorization service may maintain two different codes associated with each of a number of different clients or client devices. Transaction requests may be initiated by a transaction request system using a first code and a client identifier, and confirmed by a client device using a second code, with both codes being communicated in separate transmissions to an authorization service via potentially different networks.

BACKGROUND

Modern mobile phones, some of which may be referred to as “smartphones,”often offer many hardware and software features that were not includedin standard mobile phones less than a decade ago. For example, currentsmartphones typically include Global Positioning System (“GPS”)capability, Internet access via cellular or Wi-Fi networks, have atouchscreen, include an accelerometer or other motion sensor(s), and areoperated using an operating system capable of executing a variety ofdownloadable third-party software applications. While mobile phones withthese and other advanced features are becoming commonplace in manymarkets, there are specific markets, countries and regions in which lesstechnologically sophisticated mobile phones remain in widespread use.For example, a class of mobile phones sometimes referred to as “featurephones” typically do not have the capability to download and executesoftware applications, and may have functionality limited primarily toenabling the user to verbally communicate wirelessly and to send andreceive standard text messages (such as Short Message Service or “SMS”messages). Even in countries or markets in which more advancedsmartphones are the most common class of mobile phones used byindividuals, wireless carriers typically continue to support and providecellular service to individuals who use feature phones or other lessadvanced cellular devices.

Given the high percentage of individuals who own smartphones in manymarkets, companies have been increasingly relying on advanced hardwareand/or software features inherent in many recently manufacturedsmartphones when developing new products and services to be used inconjunctions with mobile phones. For example, a variety of products orservices enable individuals who owns certain smartphones to purchaseproducts by allowing a vendor's device to interact with radio-frequencyidentification (“RFID”) or near field communication (“NFC”) features ofmany smartphones. As another example, some third-party services requirethat a user's device is capable of communicating using certainencryption techniques or standards in order to use a given service fromthe user's mobile phone. Because many of these and other services assumeor rely upon an individual's use of a smartphone having certain minimumfunctionality, individuals who use a feature phone or other mobiledevice that is limited to more basic voice and text messagefunctionality are often unable to use such services. Alternatively, afeature phone user may be able to use some such services, but may do soin a manner that compromises (either knowingly or unknowingly to theuser) the security of the user's communications, personal information,payment information or other data because the service was designed to besecure only with respect to devices capable of functionality that ismissing in the user's device.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages will becomemore readily appreciated as the same become better understood byreference to the following detailed description, when taken inconjunction with the accompanying drawings, wherein:

FIG. 1 depicts an illustrative operating environment in which anauthorization service communicates with a transaction request system anda client device via one or more networks.

FIG. 2 is a block diagram illustrating an authorization serviceauthorizing an electronic transaction within the operating environmentof FIG. 1.

FIG. 3 depicts a general architecture of an example computing system forproviding an authorization service.

FIG. 4 is a flow diagram of an illustrative method implemented by anauthorization service for authorizing an electronic transaction and/orauthenticating the source of a transaction request.

FIG. 5 depicts an example automated text message, as displayed on amobile computing device, which may be generated by an authorizationservice.

These and other features will be described herein with reference to thedrawings summarized above. The drawings and the associated descriptionsare provided to illustrate certain embodiments and not to limit thescope of the invention.

DETAILED DESCRIPTION

Aspects of the present disclosure relate to providing enhanced securityfor a variety of electronic transactions and/or authentication attempts,which are applicable for use in a network environment in which at leastone communication associated with the transaction is likely to be sentover a network in a manner that will likely be capable of beingintercepted, listened to or monitored by an untrusted party. Forexample, one of the problems addressed by the present disclosure is thatcertain mobile computing devices (such as certain mobile phones or othercommunications devices) may be limited to receiving incomingcommunications via an unencrypted standard communication method (such asSMS messages) via wireless networks that are vulnerable to eavesdroppingby nefarious parties. There is a risk that even if a multi-systemdistributed transaction includes a number of secure communications, theentire transaction may nevertheless be considered compromised if itincludes even a single communication to one device in an insecuremanner, provided that other safeguards like those described herein arenot employed. Aspects of the present disclosure provide enhancedtransaction security and account security in such instances, in someembodiments, without requiring that the content of the potentiallyvulnerable communication (or the weak link in an otherwise securemulti-system transaction environment) be encrypted, scrambled orotherwise altered from an easily understandable form before being sentover the air or via some other potentially insecure communicationmethod.

Generally, the radio signals that carry SMS text messages are sent inthe clear, and anyone with appropriate and reasonably availableequipment can eavesdrop and capture all text messages sent in a givengeographic area. Thus, sending a standard SMS text message that includesprivileged information within the content of the message would not beconsidered secure by those of skill in the art for at least the reasonthat such privileged information would be deemed comprisable.

Known methods exist for encrypting text messages, but such methodstypically require specific hardware on the user device and/orconfiguration by a specific carrier or service provider. Becauseexisting text message encryption techniques typically requiresignificant involvement by a communications carrier (such as to supply aspecific factory-configured device) or require that customers buy andinstall additional hardware, such encryption techniques are notuniversally applicable to, or compatible with, all existing SMS-capablemobile phones without significant involvement by the carrier or anafter-market hardware provider.

Another problem addressed by the present disclosure is associated withthe possibility that a telephone number of a particular mobile phone canbe cloned for nefarious purposes. Thereafter, a hijacked device can sendand receive phone calls and text message as if it were a givenindividual's own mobile phone. The possibility of phone cloning meansthat a system receiving a text message that purportedly originated froma particular individual's mobile phone number is insufficient toestablish that the message actually originated from the given individualor even from the individual's device. The cloning problem is especiallypresent in transaction systems and methods in which a significant numberof users of the system or method utilize feature phones or other mobiledevices that lack hardware or software capabilities for encryption orotherwise enhanced communication security.

Aspects of the present disclosure, according to some embodiments,provide transaction authorization that is compatible with a featurephone (such as a phone that can receive SMS messages, but is potentiallyincapable of encryption and other more advanced smartphone features),yet precludes malicious stealing of enough user credential informationto be sufficient to authorize a transaction. In some embodiments, theenhanced security described herein may be provided even when unencryptedtext messages are intercepted or feature phones are cloned. For example,according to some embodiments, a criminal who clones a legitimate user'sphone would still lack two user-specific codes (referred to herein, forexample, as a shared code and a private code) that would be required insome embodiments to authorize a future electronic transaction on behalfof the legitimate user. Additionally, according to some embodiments, anauthorization process described herein may be such that both codes arenever sent in the same communication or even via the same network, whichmay significantly lower the likelihood that a criminal can successfullyauthorize a transaction purportedly originating from the legitimateuser.

In one embodiment, an authorization service that includes one or morecomputing devices may receive, within an encrypted transmission, anelectronic transaction request from a first remote computing system,such as a transaction request system operated by an entity that isrequesting to initiate an electronic transaction purported to have beeninitiated by a specific individual or client. The authorization servicemay then determine a client identifier and a first code within theelectronic transaction request at least in part by processing theencrypted transmission, such as by decrypting the message and extractingdata from specific fields. The authorization service may determine thatthe electronic transaction request corresponds to a given client accountat least in part by matching the client identifier within the electronictransaction request with a first client identifier previously stored inthe electronic data store, such as a data store that includes accountinformation for a potentially large number of different clients of theauthorization service. The authorization service may validate the firstcode at least in part by determining that the first code within theelectronic transaction request matches a shared code associated with thefirst account in the electronic data store. Upon validation of the firstcode, the authorization service may generate a text message thatincludes both information regarding the electronic transaction requestand a request for transaction authorization. The authorization servicemay send the text message to a mobile computing device using a phonenumber stored in the electronic data store in association with the firstaccount, such as by sending the message to the phone number inunencrypted form using SMS. When a responsive text message is receivedby the authorization service from the same mobile computing device, theauthorization service may validate the responsive text message byconfirming that at least a portion of text content within the responsivetext message matches a previously stored private code associated withthe first account in the electronic data store. If the responsive textmessage is successfully validated, the authorization service may send anelectronic transaction approval indication to the first computing systemthat initiated the transaction request. If validation fails, theauthorization service may instead send a transaction denial indicationto the first computing system.

In some embodiments, the shared code and the private code may havedistinct characteristics that reduce the likelihood of confusing onecode for the other. For example, the shared code may be a series ofnumbers and the private code may be a series of letters. As a furtherexample, the shared code or the private code may have a distinct prefixor suffix, checksum digits, or other characteristics that supportdistinguishing the codes. In further embodiments, the transactionrequest system or the mobile computing device may prevent the wrong codetype (e.g., private code instead of shared code) from being entered, ormay recognize that the wrong code has been entered and take correctiveaction. For example, the transaction request system may only allownumeric input (as opposed to letter input) when a shared code is beingentered, such as by an application executed on a transaction requestsystem displaying only number keys on a touchscreen-displayed virtualkeyboard when prompting for entry of a shared code. As a furtherexample, the transaction request system may determine that an enteredcode is not in the format of a shared code, and may display an errormessage instead of transmitting the entered code to the authorizationservice.

FIG. 1 depicts an illustrative operating environment 100 in which anauthorization service 120 communicates with a transaction request system102 and a client device 110 via one or more networks. Depending on theembodiment, the authorization service 120 may be represented in a singlephysical server or single computing device or, alternatively, may besplit into multiple physical servers or other computing devices. While asingle transaction request system and a single client device 110 areillustrated in FIG. 1 for ease of description, it will be appreciatedthat the authorization service 120 may be configured to processtransaction requests that may originate from any of a potentially largenumber of different transaction request systems located in variousgeographic locations, and may be configured to authenticate or authorizetransactions associated with any of a large number of different usersand associated client devices.

The authorization service 120 may include a client authenticator 124 anda message generator 126 stored in memory therein that may be used toimplement various aspects of the present disclosure, as will be furtherdescribed below. In some embodiments, the client authenticator andmessage generator may each be stored as computer-executableinstructions, while in other embodiments one or both of the clientauthenticator and/or message generator may be integrated withinspecialized hardware. Those skilled in the art will recognize that theclient device 110 and the transaction request system 102 may each be anyof a number of computing devices that are capable of communicating overa network. For example, the transaction request system 102 may include,but is not limited to, a laptop, desktop personal computer, tabletcomputer, point-of-sale (“POS”) system or terminal, mobile phone,smartphone, wearable computing device, gaming console, kiosk, augmentedreality device, other wireless device, set-top or other television box,or other system. The client device 110 may be any computing devicecapable of being configured to receive SMS messages or other messagesthat the authorization service 120 is configured to send in a givenembodiment, such as a mobile phone or other mobile computing device.

The authorization service 120 may be connected to and/or incommunication with various electronic data stores, such as a requestordata repository 130 and/or a client data repository 134. The requestordata repository 130 may include account records for a variety ofdifferent entities and/or systems that are each registered with theauthorization service 120 to request transaction authorizations via theauthorization service. For example, according to some embodiments, avariety of third-party companies, organizations and/or individuals mayregister with the authorization service 120 prior to any given company,organization or individual sending transaction authorization requests tothe authorization service 120. Some examples of a requestor that mayhave associated data stored in requestor data repository 130 (and whichmay also be an owner or operator of the illustrative transaction requestsystem 102) may include a vendor, a retail store, a non-profitorganization, a doctor's office, a government agency, a web siteoperator, a computer application developer or distributor, and/or anyother organization, company or individual that desires to utilize theservices of the authorization service 120 to authorize a transaction,verify a person's identity, or obtain other affiliated services providedby the authorization service 120 in a given embodiment. In otherembodiments, the authorization service 120 may be configured to acceptand process transaction requests originating from systems, companies ororganizations that are not associated with any previously registeredaccount with the authorization service 120, in which case a requestordata repository 130 may not be present.

Data or information stored in association with each transactionrequestor account in requestor data repository 130 may include arequestor account identifier and a requestor code. The requestor codemay be, for example, a series of numeric digits (such as “1033”) or maybe an alphanumeric string (e.g., “CaHt9232”). In other embodiments, therequestor code may be a significantly longer series of bits or otherdata that may be stored as a file, such as a digital certificate ortoken. In some embodiments, the data stored in association with eachrequestor account in the requestor data repository 130 may include avariety of other information regarding an owner of the account and/or atransaction request computing system or device associated with theaccount. The additional information stored in the requestor datarepository 130 in a given embodiment may depend on the type(s) ofelectronic transactions that the authorization service 120 is configuredto authorize in the given embodiment. For example, if the requestor datarepository 130 is configured to provide authorization for financialtransactions, the requestor data repository 130 may store accountbalances. As another example, if the requestor data repository 130 isconfigured to provide authorization for the release of personalinformation associated with a user or client, the requestor datarepository 130 may store information regarding the organization typethat the account belongs to and/or an associated level of informationaccess granted to the organization by the authorization service 120, byone or more clients, and/or by a third-party regulatory authority orother source.

Data or information stored in client data repository 134 in associationwith each client account may include a client account identifier, ashared code, and a private code. The shared code and private code mayeach be, but are not limited to, a series of numeric digits or analphanumeric string. In some embodiments, the shared code and privatecode may each be considered to be a different personal identificationnumber (or PIN code) associated with the client's account. The sharedcode stored for a given account would typically be different than theprivate code stored for the same account, and the authorization service120 may enforce this difference as a requirement when establishing eachcode or accepting an initial or new code from a client, in someembodiments. The shared code may be considered “shared,” in someembodiments, in the sense that a given client may be required to providehis or her shared code to other individuals or computing systems (suchas a transaction requestor entity or an associated transaction requestsystem) as part of initiating a transaction. Accordingly, the sharedcode for a given client account may not be considered secure or private,at least with respect to the knowledge of a client's shared code bythose transaction request systems or associated operators with whom thegiven client has interacted during a transaction request. In contrast,the private code of a given client may be considered private in thesense that the client can initiate and approve transactions withoutrevealing his or her private code to any entity or system other than theauthorization service 120.

As will be appreciated, other information may be stored in associationwith each client account in client data repository 134 in variousembodiments, such as a mobile phone number, a device identifier (such asa MAC address, if applicable for a given device), information regardingthe technical capabilities of the client's device (such as whether itsupports encryption or other security protocols or standards), anaccount balance, a full name, personal information, data to potentiallybe released to requestors upon transaction approval by the authorizationservice 120, and/or other information. In some embodiments, a client'smobile phone number may serve as the client's account identifier, whilein other embodiments a separate account identifier and mobile phonenumber may be stored for a given account.

In some embodiments, each of requestor data repository 130 and clientdata repository 134 may be local to authorization service 120, may beremote from the authorization service 120, and/or may be a network-basedservice itself. The requestor data repository 130 and client datarepository 134 may be embodied in hard disk drives, solid statememories, any other type of non-transitory computer-readable storagemedium, and/or a file, a database, a relational database, in-memorycache, and/or stored in any such non-transitory computer-readable mediumaccessible to the authorization service 120. The requestor datarepository 130 and client data repository 134 may also be distributed orpartitioned across multiple local and/or remote storage devices withoutdeparting from the spirit and scope of the present disclosure. In someembodiments, the data referred to herein as being stored in therequestor data repository 130 and the data referred to herein as beingstored in the client data repository 134 may be stored in a single datastore.

In the environment shown in FIG. 1, the transaction request system 102and the client device 110 each communicate with the authorizationservice 120 via the same or different communication network(s),depending on the environment. In some embodiments, the network 108 maybe a personal area network, local area network, wide area network, cablenetwork, satellite network, cellular telephone network, etc. orcombination thereof. For example, the network 108 may be a publiclyaccessible network of linked networks, possibly operated by variousdistinct parties, such as the Internet. In some embodiments, the network108 may be a private or semi-private network, such as a corporateintranet. The network 108 may include one or more wireless networks,such as a Global System for Mobile Communications (GSM) network, a CodeDivision Multiple Access (CDMA) network, a Long Term Evolution (LTE)network, or some other type of wireless network. The network 108 can useprotocols and components for communicating via the Internet or any ofthe other aforementioned types of networks. Protocols and components forcommunicating via the Internet or any of the other aforementioned typesof communication networks are well known to those skilled in the artand, thus, are not described in more detail herein. In some embodiments,the network 109 may be a cellular telephone network capable ofdelivering SMS messages to feature phones or other mobile devices. Inother embodiments, the network 109 may be any of the other network typesmentioned above or similar, including but not limited to the Internet.

FIG. 2 is a block diagram illustrating the authorization service 120authorizing an electronic transaction within the operating environmentof FIG. 1. The illustrated flow 200 begins with the transaction requestsystem 102 receiving a client device identifier (or client accountidentifier, in other embodiments) and an associated shared code. Theclient device identifier and shared code may be provided to thetransaction request system by a human operator of the transactionrequest system, such as using a keyboard, touchscreen or voice input. Insome embodiments, a person who is a client of the authorization service120 and who has previously established an account with the authorizationservice 120 may verbally provide his client identifier and shared codeto an operator of the transaction request system (such as a store clerkat a physical retail store, a doctor's office assistant, a teller at abank or some other operator) as part of an in-person interaction. Inother embodiments, some of the provided information (such as a clientdevice identifier) may be communicated from a mobile computing device orother device of the client to the transaction request system 102 whilethe client's device is physically near to the transaction request system102, such as using NFC, Bluetooth, an optical code (such as a barcode orQuick Response Code scanned by an optical reader), or RFID.

For example, a client may desire to initiate a transaction with theoperator of the transaction request system in order pay for good orservices, to establish the client's identity, to authorize release ofelectronic information regarding the client to the transaction requestsystem from the authorization service, or some other transaction purposein accord with a given embodiment. In some embodiments, the client mayprovide his mobile phone number (which may serve as the client's accountidentifier with the authorization service) to the operator of thetransaction request system for sending to the authorization servicealong with the shared code. In other embodiments, the client's accountidentifier may be a unique number, word or string previously establishedbetween the client and the authorization service to uniquely identifythe client and/or the client's account with the authorization service.One potential advantage to embodiments in which an account name otherthan a mobile phone number is utilized is that such an embodiment limitsthe ability of nefarious individuals who overhear a client speakin-person with the operator of the transaction request system fromlearning the client's phone number (which could otherwise potentiallyassist the nefarious individual in obtaining the client's private codeby subsequently searching eavesdropped cellular communications in thearea for signals originating from the phone having the given phonenumber).

Once the client identifier and shared code provided by the individualrepresenting himself to be the given client are provided to or enteredin the transaction request system 102, the transaction request system102 generates a transaction request that includes the entered clientidentifier and shared code, along with other transaction requestinformation. The other transaction request information may include arequestor identifier associated with the transaction request system 102,and a description of the requested transaction (such as a name of a goodto be purchased and an associated price, in the case of a purchasetransaction, or some other description appropriate for a non-financialtransaction). In some embodiments, the transaction request may begenerated by a software application developed by the operator of theauthorization service 120 that was previously provided to thetransaction request system (such as an application developed for a POSsystem, a tablet computer, a laptop or some other computing system usedas the transaction request system 102 in a given embodiment). In otherembodiments, the transaction information may be entered via a securewebpage (such as a webpage that utilizes Transport Layer Security,Secure Sockets Layer, or other security technology) or other secure userinterface provided by or generated by the authorization service 120 andsent to the transaction request system 102 for display. Whether thetransaction request is generated by an application associated with theauthorization service, a webpage displayed within a browser program, orin another manner, the information of the request may be encrypted bythe transaction request system 102 and/or other associated hardware(such as a network router) using known methods prior to the requestbeing communicated over a network, such as network 108. The encryptionor other security steps for protecting the network communication of theclient's shared code may prevent a nefarious party from electronicallyeavesdropping or intercepting network communications to learn of theclient's shared code, thereby providing an account safeguard in theevent that the nefarious party is able to subsequently intercept asecond code of the client's account in a later unencrypted SMScommunication.

As illustrated in FIG. 2, the transaction request generated by thetransaction request system 102 is communicated in a secure manner (suchas in an encrypted transmission and/or over a secure network) to theauthorization service 120. In some embodiments, the informationcommunicated within the encrypted transaction request may include aclient identifier, a shared code provided by the purported client to thetransaction request system, a request system identifier that identifieswith the transaction request system 102, and information regarding thenature of the transaction (such as a balance amount to be transferredfrom the client's account to an account associated with the transactionrequest system, or a request for information regarding the client). Inresponse to receiving the request, the authorization service 120 maydecrypt the transaction request and validate the provided clientidentifier, the provided shared code, and the provided request systemidentifier by comparing the provided information to previously storedidentifiers and associated codes in the requestor data repository 130 orclient data repository 134, as appropriate.

If either of the provided identifiers or the provided shared code do notmatch the stored records, the authorization service 120 may send atransaction denial indication to the transaction request system 102(denial not illustrated in FIG. 2). If the authorization service 102instead successfully validates the provided identifiers and shared code,the authorization service 120 generates an authorization request messageand sends the message to the client device 110 over a network, such as acellular network. For example, the message may be an SMS message thatincludes human-readable text information regarding the requestedtransaction (such as by identifying the requestor), and may be sent tothe mobile phone number associated with the provided client identifierin the client data repository 134.

As further illustrated in FIG. 2, the client device 110 may receive theauthorization request message (such as an SMS message received via acellular network of the client's cellular phone service provider) andmay display the message on a display screen of the client device. Theuser of the client device 110 (who is most likely the client, unless thedevice has been cloned or stolen) may then enter a responsive textmessage on the client device 110. For example, the authorization messagemay prompt the client to enter the client's private code in a responsivetext message if the client approves the transaction. In otherembodiments, it may be assumed that the client knows that entering hisprivate code in a responsive text message will approve the transaction(for example, the text content of the authorization message may notmention that a code is needed). If the client approves of thetransaction (most likely because the client was the person thatinitiated the transaction at the transaction request system 102), theclient may enter a responsive text message that includes his privatecode (such as an alphanumeric string or numeric digits) as text contentof the message, and the client device may send the responsive text as anSMS message via a cellular network to the authorization service 120. Ifthe client does not recognize the transaction (such as because theclient was not the person that initiated the transaction request), theclient may respond with message content that does not include theprivate code (such as a predetermined refusal string of “no,” in someembodiments) or may simply not respond. As will be appreciated, if theuser of the client device 110 is not the actual client (such as becausethe client's device was stolen or cloned), the user will likely not knowthe client's private code and be unable to respond to the authorizationmessage with the proper authorization.

If the authorization service 120 receives a responsive text message fromthe client device 110, the authorization service 120 searches the textcontent of the message for the client's private code (as retrieved bythe authorization service 120 from the client data repository 134). Insome embodiments, the authorization service 120 may apply one or morerules when determining whether the message provides sufficientauthorization. For example, in one embodiment the private code may berequired to be the only content of the message, while in otherembodiments the authorization service 120 may allow the client toinclude a note, memo, or other content in the message for storing in atransaction data store in association with the transaction and/or forthe authorization service 120 to provide to the transaction requestsystem 102 when confirming the transaction. If the authorization service120 successfully validates the transaction based on the client'sresponse, the authorization service sends a transaction confirmationindication to the transaction request system 102. The authorizationservice may additionally perform other transaction steps upon validationaccording to the nature of the transaction (such as altering point ormonetary balances associated with the requestor's account and the clientaccount to reflect a transfer from the client's account to therequestor's account). If the authorization service 120 determines thatthe client has not successfully validated the transaction (such asbecause the client did not respond with the correct private code withina predetermined amount of time after the sending of the authorizationrequest message), the authorization service 120 may send a transactiondenial indication to the transaction request system 102. For example, inone embodiment, the authorization service 120 may start a timer for apredetermined amount of time (such as one minute) upon sending theauthorization message, and may be configured to automatically considerthe transaction request to have failed if a validated responsive textmessage is not received back from the client device prior to expirationof the timer.

FIG. 3 depicts a general architecture of a computing system (referencedas authorization service 120) that may implement various aspects of thepresent disclosure, including communicating with both a transactionrequest system and a client device in determining whether to authorizean electronic transaction originating from a transaction request systemor other remote system. The general architecture of the authorizationservice 120 depicted in FIG. 3 includes an arrangement of computerhardware and software components that may be used to implement aspectsof the present disclosure. The authorization service 120 may includemany more (or fewer) elements than those shown in FIG. 3. It is notnecessary, however, that all of these generally conventional elements beshown in order to provide an enabling disclosure. As illustrated, theauthorization service 120 includes a processing unit 140, a networkinterface 145, a computer readable medium drive 150, an input/outputdevice interface 155, an optional display 160, and an optional inputdevice 165, all of which may communicate with one another by way of acommunication bus. The network interface 145 may provide connectivity toone or more networks or computing systems. In some embodiments, thenetwork interface 145 may include cellular communications hardware, anEthernet card, a modem, and/or WiFi communications hardware. Cellularcommunications hardware may include an antenna and other physicalcomponents such as a chip, SIM card(s), a radio transceiver, a modemand/or other hardware known in the art that is capable of sending andreceiving information via a cellular network, such as a GSM network, LTEnetwork or CDMA network. The processing unit 140 may thus send andreceive information and instructions from other computing systems orservices via a network, such as networks 108 and/or 109, and in someembodiments may interact with network interface 145 hardware to transmitand receive radio signals from a cellular network or other wirelessnetwork. The processing unit 140 may also communicate to and from memory170 and further provide output information for an optional display 160via the input/output device interface 155. The input/output deviceinterface 155 may also accept input from the optional input device 165,such as a keyboard, mouse, digital pen, microphone, touch screen,gesture recognition system, voice recognition system, image recognitionthrough an imaging device (which may capture eye, hand, head, bodytracking data and/or placement), gamepad, accelerometer, gyroscope, orother input device known in the art.

The memory 170 may contain stored computer program instructions (whichmay be grouped as modules or components in some embodiments) that theprocessing unit 140 executes in order to implement one or moreembodiments. The memory 170 generally includes RAM, ROM and/or otherpersistent, auxiliary or non-transitory computer readable media. Thememory 170 may store an operating system 174 that provides computerprogram instructions for use by the processing unit 140 in the generaladministration and operation of the authorization service 120. Thememory 170 may further include computer program instructions and otherinformation for implementing aspects of the present disclosure. Forexample, in one embodiment, the memory 170 includes a user interfacemodule 172 that generates user interfaces (and/or instructions therefor)for display upon a computing device, e.g., via a navigation interfacesuch as a browser or application installed on the computing device. Inaddition, memory 170 may include or communicate with requestor datarepository 130, client data repository 134 and/or one or more other datastores.

In addition to and/or in combination with the user interface module 172,the memory 170 may include a client authenticator 124 and a messagegenerator 126 that may be executed by the processing unit 140. In oneembodiment, the client authenticator 124 and message generator 126individually or collectively implement various aspects of the presentdisclosure, e.g., validating client identifiers and codes, generatingand sending authorization request messages, generating transactionconfirmations and denials, etc., as described further below.

FIG. 4 is a flow diagram of an illustrative method 400 implemented bythe authorization service 120 for authorizing an electronic transactionand/or authenticating the source of a transaction request. Theillustrative method 400 is similar to that described above with respectto FIG. 2, although the flow diagram of FIG. 4 is from the perspectiveof the authorization service 120, such that each block of the flowdiagram may be performed by the authorization service 120 (such as byone or more hardware processors that implement computer-executableinstructions of the client authenticator 124 and/or message generator126).

The illustrative method 400 begins at block 405, where the authorizationservice 120 receives a transaction request in an encrypted transmissionand/or via an otherwise secure communication from a transaction requestsystem, such as transaction request system 102. As discussed above, thetransaction request may include a client identifier identifying oneparty to the requested transaction, a shared code purportedly associatedwith the account of the identified client, a requestor identifieridentifying an owner or operator of the transaction request system 102(e.g., the second party to the requested transaction), as well asoptional additional information regarding the requested transaction. Atblock 410, the client authenticator 124 may extract the variousinformation elements from the encrypted transmission, such as bydecrypting the transmitted data and extracting each data element (e.g.,the client identifier, the client's code, etc.) from fields or otherportions of the transmitted request information.

At block 415, the client authenticator 124 may validate the extractedshared code by comparing the extracted code to the client's shared codestored in the client data repository 134, as previously described above.If the shared code does not match, the transaction request may be deniedand the illustrative method may end (not illustrated). If the sharedcode matches, the illustrative method proceeds to block 420, where themessage generator 126 generates an authorization message (such as an SMSmessage) for the client, as described above, and sends the message tothe client device at block 425. As previously described, the message maybe sent in an unencrypted form due to technical limitations of theclient's device, yet the overall transaction protocol may remainrelatively secure due to the other safeguards (such as the use of both aprivate and shared code that may each be sent via different networksbetween different systems).

At block 430, the client authenticator 124 may receive a responsivemessage (such as an SMS message) from the client device, likely in anunencrypted form depending on the technical capabilities of theparticular client device. As previously described with reference to FIG.2, the client authenticator 124 may then validate the client response bysearching the responsive message from the client device for the presetprivate code associated with the client's account, at block 435. Atblock 440, depending on the results of the validation block 435, theauthorization service 120 may generate and send a transactionconfirmation or denial indication to the transaction request system, aswell as perform any transaction-specific actions. A transaction-specificaction in a given embodiment may include, for example, debiting anaccount of the client, crediting an account of the requestor, releasingelectronic information (such as personal information or otherwiseconfidential information regarding the client or the client's account),releasing an electronic document associated with the client's account(such as an electronic credential, medical records, a passport,financial records, etc.) and/or any other action that a client and/ortransaction requestor may have requested and for which the authorizationservice 120 has been configured in a given embodiment.

FIG. 5 depicts an example text message 502, as displayed on a mobilecomputing device 500, which may have been generated by authorizationservice 120 and sent to the mobile computing device 500 as an SMSmessage via a cellular network. The text content of illustrative message502 reads “Confirm transaction at LAX airport? Respond with private codeto confirm.” Those of skill in the art will appreciate that the wordingof information and extent of transaction information included in themessage may vary widely depending on the transaction purpose and theembodiment. For example, in a financial transaction, the message mayindicate a monetary amount or point amount requested to be transferredfrom the client's account to an identified recipient. As anotherexample, in a transaction request for the electronic release ofinformation, the message may include an indication of the informationrequested by the requestor (e.g., “Would you like to release yourpassport information to authorities at LAX airport?”). In theillustrated example, the user of device 500 may press a physical button504 on the device 500 in order to begin composing a responsive textmessage, in which the user may enter his private code using numeric oralphanumeric buttons. In other embodiments, various different methodsand mechanisms for entering responsive text messages may be utilizeddepending on the specific hardware and software associated with theuser's device. For example, the user may provide input via atouchscreen, external keyboard, gestures, voice, or in any other mannersupported by the given device.

In some embodiments, various additional security measures may beimplemented by the authorization service beyond those described above.For example, the authorization service 120 may maintain in client datarepository 134, a third code for each client, in addition to the privatecode and the shared code described above. In some embodiments, theclient may be required to provide the third code to the authorizationservice in order to make changes to his account, such as to changeeither the given client's private code or the shared code.

According to some embodiments, the authorization service may maintain arecord of the technical capabilities of each client's device(s) inclient data repository (such as whether the device has Internet access,supports encryption, may receive push notifications, has an applicationassociated with the authorization service 120 installed on the device,etc.) and may send transaction authorization messages and othercommunications to a given client device in a different form depending onthe capabilities of the device. For example, if the authorizationservice has determined that a given client has a smartphone and/orappropriate application on his device, the authorization service 120 maysend messages to that device via an encrypted message, a pushnotification delivered via a proprietary application on the device,and/or in some other manner.

It is to be understood that not necessarily all objects or advantagesmay be achieved in accordance with any particular embodiment describedherein. Thus, for example, those skilled in the art will recognize thatcertain embodiments may be configured to operate in a manner thatachieves or optimizes one advantage or group of advantages as taughtherein without necessarily achieving other objects or advantages as maybe taught or suggested herein.

Processes described herein may be embodied in, and fully automated via,software code modules executed by a computing system that includes oneor more general purpose computers or processors. The code modules may bestored in any type of non-transitory computer-readable medium or othercomputer storage device. Some or all the methods may alternatively beembodied in specialized computer hardware. In addition, the componentsreferred to herein may be implemented in hardware, software, firmware ora combination thereof.

Many other variations than those described herein will be apparent fromthis disclosure. For example, depending on the embodiment, certain acts,events, or functions of any of the algorithms described herein can beperformed in a different sequence, can be added, merged, or left outaltogether (e.g., not all described acts or events are necessary for thepractice of the algorithms). Moreover, in certain embodiments, acts orevents can be performed concurrently, e.g., through multi-threadedprocessing, interrupt processing, or multiple processors or processorcores or on other parallel architectures, rather than sequentially. Inaddition, different tasks or processes can be performed by differentmachines and/or computing systems that can function together.

The various illustrative logical blocks, modules, and algorithm elementsdescribed in connection with the embodiments disclosed herein can beimplemented as electronic hardware, computer software, or combinationsof both. To clearly illustrate this interchangeability of hardware andsoftware, various illustrative components, blocks, modules, and elementshave been described above generally in terms of their functionality.Whether such functionality is implemented as hardware or softwaredepends upon the particular application and design constraints imposedon the overall system. The described functionality can be implemented invarying ways for each particular application, but such implementationdecisions should not be interpreted as causing a departure from thescope of the disclosure.

The various illustrative logical blocks and modules described inconnection with the embodiments disclosed herein can be implemented orperformed by a machine, such as a processing unit or processor, adigital signal processor (DSP), an application specific integratedcircuit (ASIC), a field programmable gate array (FPGA) or otherprogrammable logic device, discrete gate or transistor logic, discretehardware components, or any combination thereof designed to perform thefunctions described herein. A processor can be a microprocessor, but inthe alternative, the processor can be a controller, microcontroller, orstate machine, combinations of the same, or the like. A processor caninclude electrical circuitry configured to process computer-executableinstructions. In another embodiment, a processor includes an FPGA orother programmable device that performs logic operations withoutprocessing computer-executable instructions. A processor can also beimplemented as a combination of computing devices, e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration. Although described herein primarily with respect todigital technology, a processor may also include primarily analogcomponents. For example, some or all of the signal processing algorithmsdescribed herein may be implemented in analog circuitry or mixed analogand digital circuitry. A computing environment can include any type ofcomputer system, including, but not limited to, a computer system basedon a microprocessor, a mainframe computer, a digital signal processor, aportable computing device, a device controller, or a computationalengine within an appliance, to name a few.

The elements of a method, process, or algorithm described in connectionwith the embodiments disclosed herein can be embodied directly inhardware, in a software module stored in one or more memory devices andexecuted by one or more processors, or in a combination of the two. Asoftware module can reside in RAM memory, flash memory, ROM memory,EPROM memory, EEPROM memory, registers, hard disk, a removable disk, aCD-ROM, or any other form of non-transitory computer-readable storagemedium, media, or physical computer storage known in the art. An examplestorage medium can be coupled to the processor such that the processorcan read information from, and write information to, the storage medium.In the alternative, the storage medium can be integral to the processor.The storage medium can be volatile or nonvolatile.

Conditional language such as, among others, “can,” “could,” “might” or“may,” unless specifically stated otherwise, are otherwise understoodwithin the context as used in general to convey that certain embodimentsinclude, while other embodiments do not include, certain features,elements and/or steps. Thus, such conditional language is not generallyintended to imply that features, elements and/or steps are in any wayrequired for one or more embodiments or that one or more embodimentsnecessarily include logic for deciding, with or without user input orprompting, whether these features, elements and/or steps are included orare to be performed in any particular embodiment.

Disjunctive language such as the phrase “at least one of X, Y, or Z,”unless specifically stated otherwise, is otherwise understood with thecontext as used in general to present that an item, term, etc., may beeither X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z).Thus, such disjunctive language is not generally intended to, and shouldnot, imply that certain embodiments require at least one of X, at leastone of Y, or at least one of Z to each be present.

Any process descriptions, elements or blocks in the flow diagramsdescribed herein and/or depicted in the attached figures should beunderstood as potentially representing modules, segments, or portions ofcode which include one or more executable instructions for implementingspecific logical functions or elements in the process. Alternateimplementations are included within the scope of the embodimentsdescribed herein in which elements or functions may be deleted, executedout of order from that shown, or discussed, including substantiallyconcurrently or in reverse order, depending on the functionalityinvolved as would be understood by those skilled in the art.

Unless otherwise explicitly stated, articles such as “a” or “an” shouldgenerally be interpreted to include one or more described items.Accordingly, phrases such as “a device configured to” are intended toinclude one or more recited devices. Such one or more recited devicescan also be collectively configured to carry out the stated recitations.For example, “a processor configured to carry out recitations A, B andC” can include a first processor configured to carry out recitation Aworking in conjunction with a second processor configured to carry outrecitations B and C.

It should be emphasized that many variations and modifications may bemade to the above-described embodiments, the elements of which are to beunderstood as being among other acceptable examples. All suchmodifications and variations are intended to be included herein withinthe scope of this disclosure.

What is claimed is:
 1. An authentication system for securely authorizing an electronic transaction, the system comprising: an electronic data store configured to store authentication information associated with each of a plurality of electronic accounts, wherein authentication information for a first account of the plurality of accounts comprises at least a first client identifier, a shared code and a private code; cellular communications hardware, including an antenna, that is configured to send radio signals via a cellular network; and a physical processor in communication with the electronic data store and the cellular communications hardware, wherein the physical processor is configured with processor-executable instructions to perform operations comprising at least: receiving an electronic transaction request from a first computing device, wherein the electronic transaction request is received within an encrypted transmission via one of a wired network transmission or a wireless network transmission; determining a client identifier and a first code within the electronic transaction request at least in part by processing the encrypted transmission; determining that the electronic transaction request corresponds to the first account at least in part by matching the client identifier within the electronic transaction request with the first client identifier stored in the electronic data store; validating the first code, wherein validating the first code comprises determining that the first code within the electronic transaction request matches the shared code associated with the first account in the electronic data store; generating a text message that includes (a) information regarding the electronic transaction request and (b) a request for transaction authorization; sending the text message, via the cellular communications hardware, for delivery to a mobile computing device having a phone number that is stored in the electronic data store in association with the first account, wherein the text message is sent in an unencrypted form using a Short Message Service (SMS) communications protocol; receiving a responsive text message from the mobile computing device; validating the responsive text message, wherein validating the responsive text message comprises determining that at least a portion of text content within the responsive text message includes the private code associated with the first account in the electronic data store; and based at least in part on a determination that the at least a portion of the text content within the responsive text message includes the private code associated with the first account, sending an electronic transaction approval indication to the first computing device.
 2. The system of claim 1, wherein the operations further comprise, based at least in part on the determination that the at least a portion of the text content within the responsive text message includes the private code: sending an electronic document associated with the first account to the first computing device.
 3. The system of claim 1, wherein the operations further comprise, based at least in part on the determination that the at least a portion of the text content within the responsive text message includes the private code: modifying a stored numeric account balance associated with the first account to reflect a completed transaction.
 4. The system of claim 1, wherein the shared code is a first alphanumeric string or a first plurality of numeric digits, wherein the private code is a second alphanumeric string or a second plurality of numeric digits.
 5. The system of claim 1, wherein the first client identifier is the phone number stored in association with the first account.
 6. The system of claim 1, wherein the first client identifier and the phone number stored in association with the first account are different.
 7. The system of claim 1, wherein the electronic transaction request is received from the first computing device based at least in part on user interaction with a webpage.
 8. The system of claim 7, wherein the encrypted transmission is encrypting using one of Transport Layer Security or Secure Sockets Layer.
 9. The system of claim 1, wherein the electronic transaction request is received from the first computing device based at least in part on execution of an application by the first computing device, wherein the application was previously installed on the first computing device and is associated with an operator of the computing system.
 10. A computer-implemented method comprising: as implemented by a computer system executing specific computer-executable instructions, receiving an electronic transaction request from a first computing device, wherein the electronic transaction request is received within an encrypted transmission; determining a client identifier and a first code within the electronic transaction request at least in part by processing the encrypted transmission; determining that the electronic transaction request corresponds to a first account at least in part by matching the client identifier within the electronic transaction request with a client identifier stored in an electronic data store; validating the first code, wherein validating the first code comprises determining that the first code within the electronic transaction request matches a shared code associated with the first account in the electronic data store; generating a text message that includes a request for transaction authorization; sending the text message to a mobile computing device using a phone number stored in the electronic data store in association with the first account, wherein the text message is sent in an unencrypted form via a cellular network; receiving a responsive text message from the mobile computing device; validating the responsive text message, wherein validating the responsive text message comprises determining that at least a portion of text content within the responsive text message includes a private code previously associated with the first account in the electronic data store; and based at least in part on a determination that the at least a portion of the text content within the responsive text message includes the private code associated with the first account, sending an electronic transaction approval indication to the first computing device.
 11. The computer-implemented method of claim 10, further comprising: receiving a second electronic transaction request from a second computing device, wherein the second electronic transaction request is received within an encrypted transmission; determining a client identifier and a first code within the electronic transaction request at least in part by decrypting the encrypted transmission; determining that the second electronic transaction request corresponds to the first account; validating a first code within the second electronic transaction request, wherein validating the first code comprises determining that the first code within the second electronic transaction request matches the shared code associated with the first account in the electronic data store; generating a second text message that includes a second request for transaction authorization; sending the second text message to the mobile computing device using the phone number stored in the electronic data store in association with the first account.
 12. The computer-implemented method of claim 11, further comprising: receiving a second responsive text message from the mobile computing device subsequent to sending the second text message; determining that the second responsive text message from the mobile computing device does not include the private code previously associated with the first account in the electronic data store; and based at least in part on a determination that the second responsive text message from the mobile computing device does not include the private code, sending an electronic transaction denial indication to the first computing device.
 13. The computer-implemented method of claim 11, further comprising: determining that no text message response from the mobile computing device has been received within a predetermined amount of time after sending the second text message to the mobile computing device; and based at least in part on a determination that no text message response from the mobile computing device has been received within a predetermined amount of time, sending an electronic transaction denial indication to the first computing device.
 14. The computer-implemented method of claim 10, wherein the text message is sent using a Short Message Service (SMS) communications protocol.
 15. The computer-implemented method of claim 10, wherein the shared code is a first alphanumeric string or a first plurality of numeric digits, wherein the private code is a second alphanumeric string or a second plurality of numeric digits.
 16. The computer-implemented method of claim 10, further comprising, prior to generating the text message that includes the request for transaction authorization: confirming that a request system identifier within the electronic transaction request matches a previously stored requestor identifier.
 17. The computer-implemented method of claim 10, further comprising: in response to the determination that the at least a portion of the text content within the responsive text message includes the private code associated with the first account, sending information to the first computing device regarding an individual associated with the first account.
 18. The computer-implemented method of claim 10, further comprising: in response to the determination that the at least a portion of the text content within the responsive text message includes the private code associated with the first account, debiting an account balance stored in association with the first account.
 19. A computing system comprising: an electronic data store configured to store authentication information associated with each of a plurality of electronic accounts, wherein authentication information for a first account of the plurality of accounts comprises at least a first client identifier, a shared code and a private code; and a physical processor in communication with the electronic data store and configured with processor-executable instructions to perform operations comprising at least: receiving an electronic transaction request from a first computing device, wherein the electronic transaction request is received within an encrypted transmission; determining a client identifier and a first code within the electronic transaction request; determining that the electronic transaction request corresponds to the first account at least in part by matching the client identifier within the electronic transaction request with the first client identifier stored in the electronic data store; validating the first code, wherein validating the first code comprises determining that the first code within the electronic transaction request matches the shared code associated with the first account in the electronic data store; generating a text message that includes textual content comprising requestor information associated with the electronic transaction request, wherein the requestor information is at least one of a location or a name of a requesting entity; sending the text message to a mobile computing device using a phone number stored in the electronic data store in association with the first account; receiving a responsive text message from the mobile computing device; validating the responsive text message, wherein validating the responsive text message comprises determining that at least a portion of text content within the responsive text message includes the private code associated with the first account in the electronic data store; and based at least in part on a determination that the at least a portion of the text content within the responsive text message includes the private code associated with the first account, sending an electronic transaction approval indication to the first computing device.
 20. The system of claim 19, wherein the text message is sent in an unencrypted form using a Short Message Service (SMS) communications protocol. 